AWS再入門2023 Organizations SCP編

川原征大

2023.11.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Organizations を使ってマルチアカウント管理を推進されている方の多くは、 SCPを活用されているのではないでしょうか。 SCPは組織のセキュリティ統制、特に予防的ガードレールとして役立つ便利な機能です。

そんなSCPについて、概要や設計・運用のポイントを改めておさらいしてみます。

本ブログがSCPを活用している、もしくはこれから活用しようとされている方への参考になれば幸いです。

SCPの概要
- SCPとは
- SCPの実体
設計前のインプット
- SCPの効果範囲
- SCPはアクセス許可を与えない
- SCPの評価のされかた
- ほか細かい制限/仕様
設計のポイント
- 拒否リスト形式を採用する
- 使わないリージョンを制限する
- 管理者が作成した設定を保護する
- セキュアな利用を強制する
運用のポイント
- SCPをコードで管理する
- SCPを検証できるようにする
- SCP管理をメンバーアカウントに委任する

SCPの概要

SCPとは

Service Control Policy(SCP) は AWS Organizationsの1機能です。 SCPにより、組織内のIAMユーザー/IAMロールのアクションを制限します。

AWS環境の「予防的ガードレール」として活用できます。

📌Tips: 予防的ガードレールについて

そもそものガードレールはセキュリティ統制の考え方です。「利用者の手を止めること無く」セキュアな状態で開発できるように目指します。

ガードレールには大きく2種類あります。 実施してはいけない操作を禁止する「予防的ガードレール」 と、リスクのあるイベントを発見してアラートを行う「発見的ガードレール」です。

SCPの実体

SCPの実体はIAMポリシーです。組織のルート、OU、またはAWSアカウントへSCPをアタッチします。

デフォルトでは全てのルート、OU、アカウントに FullAWSAccess SCPがアタッチされています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

設計前のインプット

設計前に押さえておきたい、SCPの仕様や制限を記載します。

SCPの効果範囲

冒頭で言ったとおり、 SCPはルート、OU、またはAWSアカウントへアタッチできます。

そしてアタッチした効果はメンバーアカウントの、 IAMユーザー、IAMロール、そしてルートユーザーに及びます。

管理アカウントはSCPの影響を受けません 。

SCPはアクセス許可を与えない

SCP自体はIAMユーザーやロールに対して、 新たに許可を与えません 。 SCPはAWSアカウント内で実行可能な最大権限を制限するものです。

少し詳細を話します。以下はIAMの評価論理を表したフローです。

– 画像引用: ポリシーの評価論理 - AWS Identity and Access Management

枠で囲った部分がSCPによる評価パートです。 SCPパートで判決されるのは Deny のみですね。そうでない場合は次のポリシーへ判断を委ねています。ここからも SCPが許可を与えないことが分かります。

イメージとしては SCPは単なる許可 "フィルター" と考えると良いです。フィルターなので許可を通しますが、新規には与えません。

SCPの評価のされかた

あるAWSアカウント上で特定のアクションをリクエストしたとします。

そのアクションが許可されるには、 以下要素のそれぞれに明示的なAllowが必要 となります。

AWSアカウント自身
AWSアカウントの上位にあるOU
組織のルート

つまり、明示的なAllowが無いと拒否されます。デフォルトで拒否されるモデル(暗黙的な拒否)ということです。

もちろん明示的なDenyがあったときは、Allowを書いていたとしても拒否されます。

🎨 SCP評価のイメージ

例を交えてイメージを載せていきます。

(例1) SCPを有効化した際のデフォルトです。メンバーアカウントに対する制限は特にありません。

(例2) OUにアタッチした SCP(Deny IAM Actions) により、配下にあるメンバーアカウント上でIAMアクションが拒否されます。

(例3) OUでは SCP(Allow EC2 Actions) のみアタッチされています。暗黙的な拒否により、それ以外のアクションが拒否されます。

(例4) やってはいけない例です。暗黙的な拒否により、メンバーアカウント上で全てのサービス/アクションが拒否されます。

ほか細かい制限/仕様

以下の制限/仕様を押さえておきましょう。

✅ アタッチ数

各要素(OUやAWSアカウント)へアタッチできるSCPは 5個までです。

✅ 文字数制限

SCPの上限サイズは 5120文字 です。もし上限サイズに近づいている場合、空白文字を削除してスペースを節約できます。

✅ ポリシー構文

SCPはIAMアクセス許可ポリシーとほぼ同じ構文を取ります。ただ、一部表現できない記述がありします。

具体的には以下部分を押さえておくと良いでしょう。

Allowステートメントを使うとき
- NotAction と Condition は使えない
- Resource句には "*" (= 全てのリソース)しか指定できない
Action/NotAction でワイルドカードを使うとき、文字列の間には入れられない
- OKの例: "*" (= 要素自身)
- OKの例: "iam:*" , "iam:List*" (文字列の末尾)
- NGの例: iam:*Role (文字列の中間)
以下要素は使えない
- Principal/NotPrincipal
- NotResource

設計のポイント

拒否リスト形式を採用する

拒否(Deny)リスト形式は主に「Deny ステートメントのSCP」をアタッチしていく方式です。禁止させたいアクションをSCPに記述していきます。

▲ 拒否リスト形式の適用イメージ

拒否リスト形式のルールは以下のとおりです。

全ての要素には FullAWSAccess をアタッチする
各OUに「Deny ステートメントのSCP」をアタッチする

実際に適用する「DenyステートメントのSCP」のオススメについては次項で説明します。

📌Tips: 許可リスト形式

許可(Allow)リスト形式もSCP戦略の1つです。許可リスト形式では「Allow ステートメントのSCP」をアタッチしていきます。

▲ 許可リスト形式の適用イメージ

許可されるサービスやアクションを列挙します。明示的に記載したサービス、アクション以外は拒否されます。

セキュリティ要件が厳格で、使って良いAWSサービス/アクションが明示的にリストできる場合には活用できます。

ただし、一般には許可リスト形式のほうが メンテナンスコストが高い です。経験上「本来はアクセスさせたいアクションが、考慮漏れがありアクセスできない」事態が運用中に多発することが多いです。

使わないリージョンを制限する

特定リージョン上でのAWSアクセスを禁止できます。普段使わないリージョンで、意図しないリソースが作成されてコストもしくはセキュリティリスクになることを未然に防げます。

例えば東京リージョンと大阪リージョン以外で AWSアクセスを禁止したい場合は、以下のようなSCPを適用します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GRREGIONDENY",
      "Effect": "Deny",
      "NotAction": [
        # ここに禁止させたくないサービス:アクション一覧を記載する
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-northeast-3"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/ExampleOrgAdminRole"
          ]
        }
      }
    }
  ]
}

このSCPを日本語で説明すると以下のようになります。

Condition: リクエストされたリージョンが「東京、大阪」以外で
Condition: かつ、 ExampleOrgAdminRole ロールではないときに
Resource: 全リソースに対する
NotAction: 禁止させたくないサービス:アクション 以外のアクションを
Effect: 禁止する

禁止させたくないサービス:アクション には「例外なく全リージョンで必要なサービス」もしくは「グローバルサービス」を列挙します。

グローバルサービスを列挙する理由は、「これらのエンドポイントはバージニア北部 us-east-1 に設置されているものがあるため」です。例えば IAM や CloudFront などが当てはまります、

「具体的に何を列挙したほうが良いか」は Control Tower で使われているリージョン拒否コントロールの内容を参考にすると良いでしょう。

– 画像: リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否する - AWS Control Tower

※Control Tower 環境であれば、このリージョン拒否コントロールの有効化を Control Tower マネジメントコンソールから適用できます

リージョン拒否コントロールの設定 - AWS Control Tower

管理者が作成した設定を保護する

管理者が初期設定したサービスやリソースを破壊されないようにします。

例を紹介していきます。

AWSアカウントの初期設定として、AWS Configを有効化して Configルールを展開したとします。これらを無効化/削除されないようにしたいです。そんなときは以下のようなSCPをアタッチして保護できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

– 引用元: ユーザーによる AWS Config の無効化またはルールの変更を禁止する - AWS Organizations

次の例は特定リソースを保護するSCPです。特定IAMロールを管理者以外は変更できないようにします。

{    
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessWithException",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": [
        "arn:aws:iam::*:role/name-of-role-to-deny"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalARN":"arn:aws:iam::*:role/name-of-admin-role-to-allow"
        }
      }
    }
  ]
}

– 引用元: 指定された管理者ロール以外の IAM ユーザーとロールが特定の変更を行うことを禁止する - AWS Organizations

特定リソースを保護したい場合は、リソースのARN(Resource句で指定)、もしくはリソースタグ(Condition句で指定)が役立ちます。

セキュアな利用を強制する

開発者にセキュリティベストプラクティスを強制して、リスク発生を未然に防ぎます。

例を1つ紹介します。以下はEBSスナップショットをパブリックに公開させないポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyActionsPublicEbsSnapshotSharing",
      "Effect": "Deny",
      "Action": [
        "ec2:ModifySnapshotAttribute"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:Add/group": "all"
        }
      }
    }
  ]
}

– 引用元: 【小ネタ】EBSスナップショットをパブリックに公開させないポリシー | DevelopersIO

その他のユースケースは公式ドキュメントの例や DevelopersIOブログなどを参照ください。

⚠ SCP制限が強すぎると…

あまりにSCPによる制限が強すぎると、利用者の開発を阻害する事態になります。

開発の生産性を大きく下げない範囲で、効果的な制限を掛けていくことを意識します。「効果的な制限」は求められるセキュリティや利用者のスキルに応じて、異なります。